[C] Why do people write comments using /* ... */ ?
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Well yes, but what about when you are debugging ? Say you want to test two or more pieces of code ? Yes, you can do it with the preprocessor, but smeezekitty said he hates it. So, if he hates the preprocessor but doesn't mind /**/ comments everywhere, then what is his solution ? I thought maybe he had one. Of course, it could be just a rant.
Distribution: M$ Windows / Debian / Ubuntu / DSL / many others
Posts: 2,339
Rep:
The problem with abusing the preprocessor like that is the code path become unclear.
Usually I just use /* */ to comment it out. That is one disadvantage of using those
comments in code is that you lose that ability. I still don't mind them though
When I am testing sometimes I mark the code position and cut the code and paste it to another file.
When I am testing sometimes I mark the code position and cut the code and paste it to another file.
Or one can delete the code, build debug version, and then undo changes on the file (any serious editor has that functionality). Or rename a function to something else while they test its different implementation. Or add code at its beginning and add “return” at the end of the new code so that the old one is unreachable. Or even wrap the code in “if (0) { … }”.
There are so many options that I don't recall when was the last time I used “#if 0”.
and if you're using reasonable editor you probably can configure it to enter comments with some simple keystroke
Yeah, I don't know why anyone would write comment markers by hand. In Emacs, I can just use comment-dwim (M-;) which comments or uncomments the marked region. For example, with all the code marked, comment-dwim toggles between these 2:
Code:
#include <stdio.h>
int main() {
printf("hello world"); /* a comment */
return 0;
}
Certainly most IDEs can handle things properly. However, you can't just assume that everyone has a good IDE. I mean why else are Linux kernel devs so strict about style ? With a good IDE you can set your own style, but ... they're still strict about it.
Certainly most IDEs can handle things properly. However, you can't just assume that everyone has a good IDE. I mean why else are Linux kernel devs so strict about style ? With a good IDE you can set your own style, but ... they're still strict about it.
For one, code is not always read in an IDE. For example, a lot of kernel code I read, I read in my mail client (or LKML archives).
If someone writing code does not have a decent editor, then their first priority is to get one, and not worry about comment style.
I end up using #if 0 #else #endif a lot because there are some prototype projects where they change the lower sensory layers a lot because they want to test which are better, but we want to keep the capability to talk to the other ones until we reach a final conclusion. As a result it's better to take the entire function and #if 0 it out until we know which direction we're going in.
The other thing there is if you try to /* */ the whole function, any random comment in the middle of that screws your attempt up.
And #if 0 is not perfect either, you have to have legal code within it. Make a file with bad syntax or just non-code within #if 0 and it won't always compile if you happen to have syntax based terms in there, for instance ";".
All a matter of preference though. I'm glad that C is C and I rarely encounter anyone's code that is unreadable; bad maybe, but not unreadable.
I end up using #if 0 #else #endif a lot because there are some prototype projects where they change the lower sensory layers a lot because they want to test which are better, but we want to keep the capability to talk to the other ones until we reach a final conclusion. As a result it's better to take the entire function and #if 0 it out until we know which direction we're going in.
In that case, define a macro and do “#if THAT_MACRO” and not “#if 0”, e.g.:
LOL Mina86, not in the project I'm on; the hardware changes come rapidly for "experiementation" purposes and then suddenly I have to support both in one software release (therefore no preprocessor directive but instead true if-else). The coupe de grace is "can we get BOTH of those at the same time so we can parallel their data under the same test conditions?"
Nobody uses it, then everybody uses it, the suddenly an entirely new sensor is miraculously found that does it all. ... and then I'm keeping track of three sensory outputs.
No I could do that if it were my choice, it isn't.
I am saying that ultimately when they ask me to support "either or" as a configuration option, that preprocessor directives are useless at that point because all code will need to be included in the final result. And then further when they ask me to have parallel processes or threads talking to both sensors; recording the data from both at the same time so they can run a field test and compare the data - once again preprocessor directives are a moot point. In fact, in those situations, the "either or" case is a minor headache, the "both at the same time" case is an architectural expansion where I have to write a lot more code; also fully knowing that eventually much of it will be going away ... until someone long in the future says "You know ... we were getting better readings way back when we were using the <blah-blah> sensor ..." So a lot of this is the "R" part of R&D.
In thinking a bit further though on #if 0 versus #ifdef _SOME_WORDS_; I actually do not prefer unclear words for the reason that I see _TEST_MACRO_ or something like that and then I have to FIGURE OUT if that is ever declared. That's inconvenient. #if 0 is 100% clear, "This code is NOT included in the compilation".
I have a colleague who uses #ifdev _NEVER_ where they have #define _NEVER_ 0 somewhere. Yeah ... cool.
I don't mind that you choose to do what you do, please don't worry about my style. But like I say, this brief discussion has made me realize that I do like #if 0 because it is clear as to its intention.
/* */ pairs permit comments to spread over more than one line.
Unless that is you prefer a long, loopy winding, wrapped around line where the entire comment is only visible if you have set your editor to wrap lines).
So it is more useful to comment out entire chunks of code or text spread over many lines with one pair. (in // you would have to comment out each and every line and god help you in debugging if you forgot one line and more specially if you had to revert back after testing and forgot one line).
Also old c compilers may not permit //.
On the flip side, /* */ type comments within comments don't always work correctly. (// has eliminated the problem).
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.